Cómo HacerÚltima actualización 14 de septiembre de 2026

La lista de verificación legal antes de lanzar

Antes de publicar un sitio web o una aplicación, evalúe estas ocho áreas: un inventario honesto de los datos personales que recopila, una política de privacidad que coincida con ese inventario, el consentimiento manejado correctamente para el seguimiento, términos de servicio funcionales, controles reales de derechos de datos (eliminar y exportar), páginas accesibles, precios y cancelación claros si cobra dinero, y la transparencia adecuada para las funciones de IA orientadas al usuario. Nada de eso requiere un abogado para comenzar. Su constructor de IA puede ayudar a implementar los controles, pero la finalización depende de las integraciones, las decisiones comerciales y las pruebas. El orden importa más que cualquier otra cosa en esta página. El fallo legal más común en los productos creados con IA no es la falta de una política; es una política que contradice el código. La IA redacta alegremente una hermosa política de privacidad mencionando servicios que no utiliza y omitiendo el script de análisis que añadió hace tres mensajes. Así que: audite primero, luego redacte la política a partir de la auditoría. Nunca al revés. Comience con la ubicación de su empresa, los mercados a los que se dirige y lo que hace realmente su producto. Pueden aplicarse leyes de privacidad y protección al consumidor extranjeras, pero el hecho de que un sitio web sea accesible desde un país no es por sí solo un detonante legal universal. Por ejemplo, el alcance territorial del RGPD incluye el procesamiento en el contexto de un establecimiento en la UE, o una empresa fuera de la UE que ofrece bienes o servicios a personas en la UE o supervisa su comportamiento allí. Evalúe cada ley por separado. Esta guía cubre la capa que es casi universal y luego enlaza con los análisis detallados por país para Estados Unidos, la Unión Europea y Brasil.

Puntos clave

  • Evalúe conjuntamente el establecimiento, los mercados objetivo, el procesamiento, el sector y los umbrales. Un idioma o una visita extranjera incidental no son una prueba de jurisdicción completa.
  • Audite antes de redactar. Pídale a su constructor que inventaríe cada campo, cookie y tercero primero: una política escrita desde la imaginación es peor que ninguna política, porque es una declaración falsa documentada.
  • Los derechos de datos deben ser tuberías, no prosa. "Puede solicitar la eliminación" no es cumplimiento si nada en la aplicación puede eliminar realmente una cuenta.
  • El consentimiento tiene que ver con el momento oportuno: nada no esencial debería cargarse antes de que el usuario elija. Eso es un comportamiento del código, no un diseño de banner.
  • La accesibilidad es ahora un requisito legal en la UE y un imán para litigios en los EE. UU. WCAG 2.1 AA es el estándar de trabajo en casi todas partes.
  • La IA es un buen ingeniero de cumplimiento y un mal asesor de cumplimiento. Úsela para construir los mecanismos; use a un humano para las decisiones de juicio.

Qué determina qué leyes se aplican a usted

Cinco preguntas, en orden de cuánto cambian su respuesta:

  1. ¿Dónde está establecida la empresa y a quién se dirige o supervisa? La mera accesibilidad no es suficiente para la prueba de segmentación del RGPD. Revise su marketing, clientes, cobertura de entrega y supervisión del comportamiento.
  2. ¿Qué recopila? Un sitio de folletos aún puede procesar direcciones IP a través de registros de alojamiento, incrustaciones y análisis. Agregue un campo de correo electrónico y tendrá los deberes de un controlador de datos. Agregue datos de salud, biométricos, de ubicación precisa, financieros o de niños y saltará a un nivel mucho más estricto.
  3. ¿Recibe dinero? Los pagos traen consigo leyes de protección al consumidor: transparencia de precios, derechos de reembolso y desistimiento, reglas de suscripción y cancelación, registro fiscal.
  4. ¿Los usuarios crean contenido o hablan entre ellos? El contenido generado por el usuario conlleva deberes de moderación, mecanismos de notificación y retirada y reglas de responsabilidad.
  5. ¿Podrían usarlo menores? No "es para niños", sino ¿podría un niño de 12 años registrarse de manera plausible?. Las reglas para niños son las más estrictas, las menos indulgentes y las más costosas si se hacen mal.

Los umbrales y las excepciones son específicos de cada ley. Algunas leyes estatales de privacidad utilizan pruebas de volumen o ingresos; otras reglas dependen de la actividad o el tipo de datos. Consulte la guía del país relevante en lugar de tratar el tamaño de la empresa como una exención universal.

Las diez cosas que casi todos los productos necesitan

1. Una identidad visible. ¿Quién está legalmente detrás de esto? Un nombre comercial, un método de contacto real y, en gran parte de Europa, una dirección y un número de registro. Los sitios comerciales anónimos no cumplen con la normativa en varios países y no son confiables en ninguno de ellos.

2. Una política de privacidad que coincida con el código. Qué recopila, por qué, cuánto tiempo lo conserva, con quién lo comparte, qué derechos tienen los usuarios y cómo comunicarse con usted.

3. Consentimiento manejado en el momento adecuado. Análisis, píxeles, widgets de chat, videos incrustados, fuentes personalizadas cargadas desde una CDN de terceros: todos estos pueden configurar cookies o filtrar direcciones IP antes de que el usuario haya aceptado nada.

4. Términos de servicio. El contrato: qué hace el servicio, qué no pueden hacer los usuarios, pago y cancelación, límites de responsabilidad, qué tribunales del país deciden las disputas. La ley de protección al consumidor prevalece sobre cualquier cosa injusta que ponga aquí, así que no se exceda con el lenguaje legal.

5. Derechos de datos funcionales. Acceso, corrección, eliminación, exportación y el derecho a oponerse al marketing. Construya los botones.

6. Conceptos básicos de seguridad. Contraseñas con hash, secretos que no estén en el código del lado del cliente, rutas de administración realmente protegidas, reglas de base de datos que no permitan que el usuario A lea los registros del usuario B. Pregúntele a su constructor explícitamente: las aplicaciones creadas con IA suelen enviarse con reglas de base de datos permisivas más a menudo que cualquier otra cosa en esta lista.

7. Accesibilidad. Navegación por teclado, contraste de color, etiquetas de formulario, texto alternativo, encabezados sensatos. WCAG 2.1 Nivel AA es el estándar de referencia, y ahora es un requisito legal para muchos servicios orientados a la UE.

8. Comercio honesto. Precio total con impuestos antes del botón de pago, fechas de renovación indicadas por adelantado, cancelación tan fácil como el registro y un recibo.

9. Niños. Si los menores pueden acceder a él de manera plausible, necesita un control de edad y una postura de datos diferente: generalmente sin publicidad conductual, sin creación de perfiles y con consentimiento de los padres por debajo de un umbral que varía según el país.

10. Divulgación de IA. Si un usuario está hablando con un bot, generando contenido o siendo calificado por un modelo, dígalo. Los deberes de divulgación dependen del sistema, el uso y la jurisdicción; no implique que la codificación asistida por IA por sí sola los activa.

Lo que su constructor de IA puede y no puede hacer

Es genuinamente bueno en: inventariar su propio código, listar cada llamada de terceros, construir un banner de consentimiento que realmente bloquee scripts, conectar flujos de eliminación/exportación, ejecutar una prueba de accesibilidad, agregar texto de divulgación, endurecer las reglas de base de datos y redactar una política basada en hechos que usted le proporcione.

Le fallará en: saber en qué jurisdicción se encuentra, conocer el nombre de su entidad legal o los períodos de retención, juzgar si se aplica el "interés legítimo" o decirle cuándo ha cruzado a un territorio regulado. También (y esto es lo peligroso) redactará una política profesional y segura llena de detalles inventados si le pide que "agregue una política de privacidad". Ese documento es una declaración pública sobre su negocio. Trate todo lo que genere como un borrador con marcadores de posición, no como un documento legal terminado.

Dos cosas que no puede hacer en absoluto: firmar un acuerdo de procesamiento de datos con sus proveedores en su nombre, y asumir la responsabilidad. Clasifique a cada proveedor por su función real: procesador, controlador independiente o, a veces, controlador conjunto. Un procesador necesita los términos de procesamiento apropiados; un proveedor no es automáticamente su subprocesador.

La secuencia de comandos (ejecútelos en orden)

Puede adaptarlos para Base44, Lovable, v0 o cualquier constructor basado en chat. Ejecútelos en orden: cada uno depende de la salida del anterior.

1. Inventaríe lo que realmente tiene

Audit this application and produce a DATA INVENTORY as a table. For every place personal data is collected, stored, or sent, list:
1. The field name and exactly where it is collected (page, form, component).
2. Why it exists, and whether any code in the app actually reads it.
3. Where it is stored (which table or collection) and any retention logic.
4. Every third party it reaches: analytics, error tracking, email, payments, maps, fonts, embeds, AI providers. Name the service and what data it receives.
5. Whether it is sensitive data: health, biometric, precise location, financial, government ID, data about children, or race/religion/political/sexual-orientation data.

Then list separately every cookie, every localStorage/sessionStorage key, every tracking script, and every asset loaded from a third-party domain.

Report only what exists in the code. If you are unsure whether something collects personal data, list it as UNKNOWN rather than guessing. Do not write a privacy policy yet.

2. Recopile menos

Using the data inventory above, propose a minimization pass. For each field, mark KEEP (and state the specific reason it is required), MAKE OPTIONAL, or REMOVE. Flag every field we collect but never read anywhere in the application. Do not change anything yet — give me the table and wait for my approval, then implement the approved changes one at a time.

3. Redacte las páginas legales a partir del inventario

Create three pages — Privacy Policy, Terms of Service, and Cookie Policy — and link all three in the footer of every page and in the signup flow.

Rules:
- Base the Privacy Policy strictly on the data inventory you produced. Do not add categories of data we do not collect. Do not name services we do not use.
- Wherever a fact must come from me, insert a clearly marked placeholder such as [[LEGAL ENTITY NAME]], [[BUSINESS ADDRESS]], [[CONTACT EMAIL]], [[RETENTION PERIOD]], [[GOVERNING LAW]] — never invent one.
- Add a visible "Last updated" date to each page.
- Write in plain language a non-lawyer can read.

When you are done, list every placeholder you inserted, and list anything in these documents you are not confident about.

4. Haga que el consentimiento se comporte correctamente

Implement consent for tracking with these rules, and treat them as behaviour, not design:
- No non-essential cookie, analytics script, advertising pixel, chat widget or third-party embed loads before the user makes a choice.
- "Accept all" and "Reject all" are equally prominent on the first screen — same size, same colour weight, same position priority — plus a "Manage preferences" option with granular categories.
- Nothing is pre-selected except strictly necessary cookies.
- The choice persists across pages and sessions, and can be changed at any time from a permanent link in the footer.
- Store each choice with a timestamp and the version of the consent text shown.

Then report: which scripts are now blocked before consent, and confirm that a fresh visit fires no analytics or advertising request until a choice is made.

5. Construya derechos de datos reales

Add working user data controls — actual functionality, not policy text:
1. "Download my data": exports the approved scope of that user’s personal information in a machine-readable file, excluding other people’s data, secrets and privileged material. Verify identity and authorization server-side.
2. "Delete my account": deletes or irreversibly anonymizes the user's records, and before confirming, shows the user exactly what will be retained and why (for example invoices kept for tax law).
3. A way for users to correct their own profile data.
4. An internal log of each request with its date and outcome.

All three must be reachable in at most two clicks from account settings. Then tell me exactly which tables each action touches — and, importantly, what it does NOT reach: backups, logs, analytics, and any third-party service holding a copy. I need the gaps listed explicitly.

6. Bloquee los agujeros de seguridad obvios

Review this app for the security issues that create legal exposure, and report findings before fixing anything:
- Database rules: can any authenticated user read or write another user's records? Show me the rule for each table.
- Are any API keys, secrets or credentials present in client-side code or in the repository?
- Are admin routes and admin-only actions enforced on the server, or only hidden in the UI?
- Are passwords hashed, and are password reset and session expiry handled properly?
- Is any personal data written to logs or error tracking?
- Is real personal data present in seed, demo or test data?

List each finding with its severity and location. Then fix them one group at a time, starting with the database rules.

7. Ejecute una prueba de accesibilidad

Audit the entire application against WCAG 2.1 Level AA and report the findings grouped by severity, with the file or component for each. Check at minimum: colour contrast, keyboard-only navigation and visible focus states, form labels and error messages, alt text on meaningful images, heading order, link text that makes sense out of context, and behaviour at 200% zoom and on small screens. Do not fix anything yet.

Luego, después de leerlo: Corrija los problemas de accesibilidad críticos y graves, en grupos, comenzando con la navegación por teclado y las etiquetas de formulario. Después de cada grupo, dígame qué cambió y qué sigue pendiente.

8. Divulgue la IA

Find every place in this app where AI generates or influences what the user sees or what happens to them: chat, recommendations, scoring or ranking, auto-replies, generated text or images, content moderation. For each one, tell me whether the user is currently told it is AI.

Then add a clear disclosure at the first point of interaction wherever it is missing, and add a section to the privacy policy stating which AI provider processes user input and what happens to that input. If you do not know whether inputs are retained or used for training by that provider, say so explicitly rather than guessing.

9. Haga que los flujos de dinero sean correctos

Review every paid flow and make these true:
- The total price including taxes and any recurring charge, its frequency, and the next renewal date are all visible before the payment button.
- The payment button itself states that it creates a payment obligation.
- Accepting the terms requires an explicit action; nothing is pre-ticked.
- Cancellation is available from the account area in at most two clicks, with no retention offer, survey or phone call in the way.
- An email confirmation is sent containing the order details and the cancellation instructions.

List every screen you changed, and list any flow where you could not implement one of these and why.

10. Verificación previa al lanzamiento

Run a pre-launch compliance check. Report as a checklist with PASS, FAIL or UNKNOWN for each item — answer UNKNOWN rather than guessing:
1. Privacy Policy, Terms of Service and Cookie Policy exist, are linked in the footer of every page, and contain no unfilled placeholders.
2. Business identity and a working contact method appear on the site.
3. No analytics or advertising request fires before consent, and consent can be withdrawn.
4. Account deletion and data export work end to end.
5. Every form states, at the point of collection, what the data will be used for.
6. No test or demo data, no real personal data in seed data, no secrets in client-side code.
7. Every marketing email includes an unsubscribe link and a postal contact.
8. AI features disclose that they are AI.
9. The documented children’s-scope assessment has been implemented; any age assurance is proportionate and minimizes identity data.
10. Legal pages, consent UI and error messages exist in every language the product is offered in.

For every FAIL and UNKNOWN, tell me what would fix it.

Cómo difieren las tres regiones, en una tabla

Estados UnidosUnión EuropeaBrasil
Qué lo pone en alcanceVender o dirigirse a residentes de estados específicos, generalmente por encima de umbrales de volumen/ingresosOfrecer bienes o servicios a personas en la UE, o supervisarlas: sin umbral de tamañoProcesar datos de personas en Brasil, u ofrecer bienes o servicios a Brasil
Ley de privacidad principalLeyes integrales estatales más reglas sectoriales federales y estatalesRGPDLGPD
Consentimiento de seguimientoPrincipalmente exclusión voluntaria (opt-out); varios estados requieren respetar las señales de exclusión voluntaria del navegador (GPC)Inclusión voluntaria (opt-in) antes del seguimiento de dispositivos no exentosConsentimiento para cookies no esenciales; la ANPD espera botones iguales de aceptar/rechazar
NiñosCOPPA menor de 13 años (cumplimiento total desde el 22 de abril de 2026) más leyes estatales de edad de la tienda de aplicacionesEdad de consentimiento del RGPD 13–16 por estado miembro, más deberes de la DSAECA Digital (Lei 15.211/2025) en vigor desde el 17 de marzo de 2026
AccesibilidadSin regla web federal para empresas privadas, pero litigios ADA pesados; WCAG 2.1 AA es el estándar de factoLey Europea de Accesibilidad desde el 28 de junio de 2025; EN 301 549 / WCAG 2.1 AALBI (Lei 13.146/2015) más ABNT NBR 17225:2025
Venta en líneaROSCA más ~30 leyes estatales de renovación automática; nexo de impuesto sobre las ventas por estadoDerecho de desistimiento de 14 días; función de desistimiento para contratos cubiertos desde el 19 de junio de 2026Derecho de arrepentimiento de 7 días del CDC; deberes de divulgación del Decreto 7.962/2013
Reglas de IASin ley federal única; reglas de engaño de la FTC más estatutos estatales de IATransparencia del Artículo 50 de la Ley de IA desde el 2 de agosto de 2026Aún no hay una ley integral de IA; proyecto de ley pendiente
Quién hace cumplirFiscales generales estatales, FTC y demandas privadasAutoridades nacionales de protección de datos; multas de hasta el 4% de la facturación globalANPD, Procon y tribunales de consumo

Cada fila es un resumen: los análisis detallados explican los umbrales y las exenciones: Estados Unidos · Unión Europea · Brasil.

Cuatro mercados más, cada uno con su propio giro: el Reino Unido, donde los análisis estadísticos limitados pueden calificar para una excepción de consentimiento y el alcance de la Ley de Seguridad en Línea tiene exenciones; Canadá, donde CASL reconoce el consentimiento expreso y el implícito calificado, y Quebec agrega sus propias reglas de privacidad e idioma; Australia, donde una pequeña empresa aún puede quedar fuera de la Ley de Privacidad mientras la divulgación de decisiones automatizadas y el desarrollo del código para niños tienen hitos en diciembre de 2026; y Israel, donde la Enmienda 13 amplió la aplicación de la privacidad y también importan las reglas sobre spam y accesibilidad.

Derechos de contenido, revisiones y relaciones de afiliados

Mantenga un registro de permiso o licencia para fotos, fuentes, videos y otros activos. Use testimonios reales con el permiso apropiado y no invente resultados de clientes, piezas de portafolio o reseñas. La mejora con IA de su propio trabajo real puede mejorar la presentación; no genere trabajo o evidencia de antes y después que nunca existió.

Si una recomendación genera una comisión u otro beneficio, revele esa relación claramente cerca de la recomendación. Una política de pie de página por sí sola puede no explicar una conexión material en el punto en que los lectores confían en ella. Consulte la guía de respaldo de la FTC.

Para las cargas de los usuarios, separe la licencia que solicitan sus términos de su proceso de notificación y eliminación. No asuma que escribir "los usuarios son responsables" resuelve sus propios deberes.

Cuándo contratar a un abogado realmente

Hágalo usted mismo con los mensajes anteriores si está creando un sitio de folletos, un portafolio, un formulario de reserva, un pequeño SaaS con datos de cuenta comunes o una herramienta interna. Involucre a un profesional (correctamente, antes del lanzamiento) si algo de esto es cierto:

  • Maneja datos de salud, biométricos, financieros o de ubicación precisa, o cualquier cosa sobre niños.
  • Está creando en un sector con licencia: atención médica, finanzas, seguros, servicios legales, juegos de azar, alcohol, registros educativos.
  • La función principal de su producto es la creación de perfiles, calificación o decisiones automatizadas sobre personas: crédito, contratación, vivienda, seguros, educación.
  • Está recibiendo inversión, o sus flujos de datos son una pregunta de diligencia debida.
  • Está procesando datos personales a gran escala, o actuando como un mercado entre otras partes.
  • Ha recibido una carta de demanda, una consulta de un regulador o una queja de un sujeto de datos: deténgase y obtenga ayuda de inmediato, no responda desde una plantilla.

Una revisión de dos horas de un borrador que ya preparó es drásticamente más barata que un abogado que comienza desde una página en blanco. Ese es el verdadero retorno de ejecutar la secuencia de mensajes: usted llega con un inventario de datos y un borrador, no con una pregunta.

Mantenimiento: esta no es una tarea de una sola vez

Cada vez que agrega una función que recopila algo nuevo, agrega un servicio o activa una nueva integración, su inventario cambia y su política ahora está ligeramente equivocada. El ritmo saludable: vuelva a ejecutar el mensaje 1 cada vez que lance algo que toque datos, y vuelva a ejecutar el mensaje 10 antes de cualquier lanzamiento importante. Dos veces al año, vuelva a leer su propia política como un extraño y verifique que todavía describe su producto.

Qué establecen las verificaciones de construcción

Los mensajes son solicitudes de implementación, no una certificación legal. Los controles de dos clics y los valores predeterminados de consentimiento primero son opciones de diseño prácticas, no requisitos legales universales. Confirme la jurisdicción, las exenciones, la retención y los contratos de proveedores por separado. Verifique los controles con cuentas de prueba y el comportamiento real del navegador/red; el APROBADO de un constructor basado solo en la inspección del código es evidencia incompleta.

Fuentes oficiales y alcance de la revisión

Actualizado el 14 de septiembre de 2026. Las fuentes vinculadas respaldan el alcance y las correcciones discutidas aquí; esta es una revisión editorial, no una opinión legal exhaustiva ni una certificación de su producto. Verifique la regla operativa al actuar.

Láncese legal, no con suerte. Ejecute los diez mensajes anteriores antes de conectar su dominio, luego lea el análisis detallado de su mercado más grande: Estados Unidos, Unión Europea, Reino Unido, Canadá, Australia, Brasil, Israel. Y si aún no ha construido la cosa, comience con De la idea a la aplicación en vivo. Usted puede construir esto.

Preguntas Frecuentes

EveryoneBuilds Editorial Team
We research, test, and compare AI app builders so you don't have to.

Usamos cookies para analizar el tráfico y rastrear clics de afiliados. Al continuar, aceptas nuestra Política de Privacidad.